System and method for purchasing using biometric authentication

ABSTRACT

A system and method for registration and processing point of sale purchases, billing and transaction requests using biometric authentication is provided. The system is configured such that upon registration of a user token on a mobile device, an associated financial account server is prevented from processing any transaction requests against the associated account without confirmation and receipt of a user token from a server. The system interacts with the mobile device to verify a biometric identifier before transmission of the user token from a server that interacts with a second server of the financial institution associated with the account before processing a transaction request. The system also includes methods to configure multiple point of sale systems at retail locations to communicate and process payment requests through the system.

FIELD OF THE INVENTION

Example embodiments relate to a method for supporting cashless paymentusing a mobile communication device.

BACKGROUND OF THE INVENTION

Today's consumer financial accounts systems have been significantlyaffected by fraudulent transaction activity, where a consumer'sfinancial accounts can be subject to fraudulent account transactionswithout their knowledge. Financial institutions have tried repeatedly tocurb these activities by putting in extra security measures in onlineand credit/debit card transactions, such as longer passwords, encryptionand computer chips on credit/debit cards. However, this approach has noteliminated the fact that once a fraudulent transaction has circumventedthese measures, the fraudulent transaction will still occur and, atbest, be refunded to the consumer at some time after the occurrence ofthe transaction.

Further, systems in the cashless payment space have methods for carryingout financial transactions using a mobile telephone system. While thesemethods add additional layers of security, they are not without inherentshortcomings. There, an electronic connection between the point of saleterminal and the mobile telephone network is established. Access to amerchant's payment system is provided via this connection. The userenters or scans a card identifying number into the terminal. Anauthentication is performed based on the entered card identificationnumber and user-identifying data read from the SIM card of a mobiledevice. Then, a connection between the point of sale terminal and thepayment service provider's payment system is established and the amountto be paid, a confirmation of amount and an approving method of paymentare given to the service provider's payment system. While this methodhas built in security due to the confirmation of the SIM card of themobile device, if a consumer's card containing the card identifyingnumber has been stolen or cloned, the fraudulent activity can stilloccur without the consumer's knowledge. Accordingly, it is an object ofthe present invention to improve the current cashless payment systems byproviding a more secure method of performing cashless paymenttransactions.

SUMMARY OF THE INVENTION

Some example embodiments may enable a method for supporting cashlesspayment using a mobile communication device, wherein the mobilecommunication device provides an authentication method and user tokenwhich interacts with a mobile application of the mobile communicationsdevice for granting access to a lockbox server, the method comprises thesteps of: transmitting the user token stored in the mobile communicationdevice's memory to a lockbox server; the lockbox server transmittingcommands to the financial institution upon verification of the usertoken received from the lockbox server to perform processing and paymenttransfer, if the received user token has been verified and correct. Thefinancial institution, after registration of the user token, will notprocess any financial requests without receipt of commands from thelockbox server.

In another embodiment a point of sale unit using a communication method,such as a mobile communication device, the mobile communications devicereceives the user token from the mobile communication device on requestof the a merchant's point of sale unit, transmits the user token to alockbox server or to a point of sale unit for forwarding to the lockboxserver, for processing a payment transaction request. This object isfurther achieved by a computer program product for a cashless paymentsystem using such mobile communication device, wherein the computerprogram product, when executed by a mobile communications device,performs the aforementioned functions.

This invention is built on the idea to have a mobile based verificationsystem between the retail or merchant services and the financialinstitution server which simulates vis-a vis the verification functionan exchange with the mobile communication network.

The present invention increases the efficiency of the cashless paymentsystem. The cashless payment system does not require its ownauthentication and authorization algorithm. Further, it is not necessaryto handle specific personal identification numbers (PINS) or transactionnumbers (TANS). Already existing powerful mechanisms of a mobilecommunication device are reused to provide identification andauthentication without the requirement to use this mobile communicationdevice and establish a bearer connection via this mobile communicationnetwork. The invention provides a secure, cost efficient and userfriendly authentication of the cashless payment system. Furtheradvantages are achieved by the embodiments of the invention indicated bythe dependent claims.

According to an embodiment of the invention, the mobile communicationsdevice is connected to a point of sale unit (MERCHANT SERVICES—Point ofSales) via a short-range interface and at least a part of thecommunication between the mobile communications device and the paymentinterworking server is carried over this point of sale unit. The shortrange interface is, for example, a short range radio interface like aBluetooth interface or an infrared interface. This makes it possible toimplement an easy to handle and user friendly payment process: A mobilecommunications device can remain in the pocket of the user which standsin the neighborhood of the point of sales unit. The amount to be paid,the confirmation of the user and/or the approving of payment by the usercan be entered in the point of sales unit, without any user interactionbetween the mobile communications device and the user. The exchange of auser token can be automatically executed between the merchant servicesand the mobile communications device via the short range interface.Further, it is also possible that authentication of a transaction mayoccur at the mobile communications device.

Further, it is also possible that the mobile communications device andthe point of sale unit are connected via a long distance communicationnetwork and the point of sale unit is formed by an internet-server whichprovides an electronic shopping experience.

Some advantages are achieved when carrying the whole communicationbetween the mobile communications device and the payment interworkingserver via the point of sale unit. The point of sale unit has fullcontrol over the data flow which increases the security and efficiencyof the system. For example, the point of sale unit forwards the usertoken to the interworking unit solely when the user has confirmed theamount and has approved the payment. This reduces the work load of thepayment interaction unit and increases the security of the system.

Further, the method can be easily adapted to different billing systemsand seller's needs: It is possible that the point of sale unit initiatesthe payment when receiving the confirmation message from the lockboxserver. Thereby it is possible to combine the method according to theinvention with low-price cashing systems. But, it is also possible thatthe billing system initiates the payment when receiving the confirmationmessages from the lockbox server and sends a confirmation to the pointof sale unit about this payment. Further advantages are achieved, ifthis billing system is a billing system of the mobile operator of themobile communication device. This system charges the user's mobileoperator's account when receiving the confirmation message from thelockbox server.

Further, the security of the system can be increased by encrypting thecommunication between the mobile communications device and the lockboxserver. According to a preferred embodiment of the invention, the mobilecommunications device encrypts the user token before sending it to thepoint of sale unit and the payment interworking server decrypts thereceived mobility subscriber identity, when receiving it from the pointof sale unit. Thereby, the user token is protected against fraudulentissues.

BRIEF DESCRIPTION OF THE DRAWINGS

These as well as other features and advantages of the invention will bebetter appreciated by reading the following detailed description ofpresently preferred exemplary embodiments taken in conjunction withaccompanying drawings of which:

FIG. 1 is a block diagram showing a mobile registration system forcreating a cashless payment system having a lockbox server, according tothe invention.

FIG. 2 is a block diagram of an embodiment of the cashless paymentsystem transaction method, according to the invention.

FIG. 3 is an alternate embodiment of the lockbox server as it is used ina typical retail enterprise configuration.

The present drawings are not necessarily drawn to scale. Repeat use ofreference characters in the present specification and drawings isintended to represent same or analogous features or elements of theinvention according to the disclosure.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Some example embodiments now will be described more fully hereinafterwith reference to the accompanying drawings, in which some, but not all,example embodiments are shown. Indeed, the examples described andpictured herein should not be construed as being limiting as to thescope, applicability, or configuration of the present disclosure. Likereference numerals refer to like elements throughout. As used herein,“in communication” should be understood to refer to direct or indirectconnection that, in either case, enables functional communication ofcomponents that are operably coupled to each other.

Further, the term “or” as used in this disclosure and the appendedclaims is intended to mean an inclusive “or” rather than an exclusive“or.” That is, unless specified otherwise, or clear from the context,the phrase “X employs A or B” is intended to mean any of the naturalinclusive permutations. That is, the phrase “X employs A or B” issatisfied by any of the following instances: X employs A; X employs B;or X employs both A and B. In addition, the articles “a” and “an” asused in this application and the appended claims should generally beconstrued to mean “one or more” unless specified otherwise or clear fromthe context to be directed to a singular form. Throughout thespecification and claims, the following terms take at least the meaningsexplicitly associated herein, unless the context dictates otherwise. Themeanings identified below do not necessarily limit the terms, but merelyprovided illustrative examples for the terms. The meaning of “a,” “an,”and “the” may include plural references, and the meaning of “in” mayinclude “in” and “on.” The phrase “in one embodiment,” as used hereindoes not necessarily refer to the same embodiment, although it may.

As shown in the accompanying figures, the present invention is directedtowards a system and method for accomplishing secure purchases using amobile device. Additionally, these purchases can be “in person”, orpreauthorized transactions that are confirmed and completed remotelyusing a mobile device. Security in this system is established by virtueof only allowing financial transactions to occur against a user's bankaccount by first authenticating the transaction through the transfer andverification of an authentication token from a user's associated mobiledevice to a secure lockbox server. The lockbox server will then passconfirmation to the merchant, the credit card company, issuing bank orlike financial institution which already has custodial responsibilitiesfor the financial account or data associated with a given user'sfinancial account. Otherwise, the users' financial account is locked andfinancial transactions cannot be performed against the account.

More specifically, with reference to FIG. 1, the system and attendantmethod is instigated by the user creating a secure user token based on abiometric scan performed by the user which is stored for use to createthe user token, wherein FIG. 1 depicts a mobile registration system 1 toenable registration and interaction of the mobile communication device 2with the lockbox server 3 according to this invention. The mobilecommunication device 2 is formed by a cellular mobile device, forexample according to the GSM or UMTS standard (GSM=Global System forMobile Communication; UMTS=Universal Mobile Telecommunications) or IS-95or CDMA2000 standard. Such devices communicate with several serverswhich interact with the mobile communication device 2 for granting themobile communication device 2 access to a mobile communication network.Exemplary, FIG. 1 shows a GSM based mobile communication device 2 incommunication with a lockbox server 3, which is formed by a machineserver. This machine server can be configured from a physical server ora virtual server without departing from the scope of this invention.

At the mobile communication device 2, on first use of a mobileapplication downloaded and stored on the mobile communication device 2,the mobile application will request the user to register the mobilecommunication device 2 to interact and communicate with the lockboxserver 3. This registration process includes first capturing and storinga biometric scanned identifier in the memory of the mobilecommunications device 2. The user will store a biometric scan of thebiometric identifier, such as a finger print, facial or other biometricscan. The biometric identifier can also be an eye scan, a facialrecognition scan or any other uniquely scanned feature that is specificto the user. The biometric scanning and storing can be performed by anytraditional method, such as image capturing or thin film piezo scanning.The mobile application stores the biometric identifier in the memory ofmobile communication device 2. If storage is successful, the mobileapplication will then associate the mobile device identifiers (any orall of the IMEI, SIM, UCID or device serial number) of the mobilecommunication device 2 with the stored biometric identifier to create auser token 4. The user token 4 will provide the means for authenticatingthe mobile communication device 2 for communication with the lockboxserver 3. The mobile application will then pass the user token 4 to thelockbox server 3. Each financial account later associated with the useraccount 5 at the lockbox server 3 will receive a unique token 4 composedof the biometric identifier, the mobile device identifier and financialaccount information to insure a safe and secure user experience. Theuser token 4 consolidates all the user's mobile communication device 2identifiers with the biometric identifiers and financial accountinformation to insure the user token 4 cannot be replicated, duplicatedor fraudulently used if their device is lost or stolen. Each user token4 is unique for each account associated with the mobile communicationdevice 2. This allows the user to store multiple digital debit, creditor check cards from the same or multiple financial institutions and/orutilize the traditional card swipe or chip reading process from themerchant service or retailer's mag-strip reader.

Upon transfer of user token 4 to the lockbox server, the lockbox server3 will then create a user account 5, based on the user token 4, and theuser account 5 is stored in a memory at the lockbox server 3. The usertoken 4 will provide authentication to the lockbox server 3 thatfurthers communications being received from the mobile communicationdevice 2 have been verified and are coming from the intended source. Alldata created, received, transmitted and stored on the lockbox server 3is encrypted with the (Advanced Encryption Standard) AES, or othersuitable encryption methods. Upon device registration and accountcreation, the lockbox server 3 then passes back to the mobilecommunication device 2 a successful confirmation that the mobilecommunication device 2 has been authenticated to then verify, confirmand request financial transactions that will be sent to the user'sfinancial institution, as later described below.

Each time the mobile communication device 2 requests communication withthe lockbox server 3 the user token 4 is transmitted to the lockboxserver 3, the lockbox server 3 verifies the mobile communication device2 by comparing the transmitted user token 4 with the user token 4previously stored and the user account 5 on the lockbox server 3. If thesigned result is correct, the lockbox server 3 grants access to themobile communication device 2 and its mobile application toauthenticate, submit or request a transaction.

The lockbox server 3 can store multiple different user tokens 4associated with financial accounts authenticated for the mobilecommunication device 2. Accordingly, a single user may authenticatefinancial transactions for multiple financial accounts from a singlemobile communications devices 2. For example, the user may have businessrelated accounts and personal accounts where different transactions maytake place and need to be authorized by the mobile communications device2. The lockbox server 3 can reside in any location that is accessible bythe mobile communication device 2 and the user's financial institution,which includes, but it not limited to the financial entities' physicalprocessing and server location, at a remote secure hosting facility, ora connected cloud server. Regardless of the location selected, thelockbox server 3 has now become the gateway for all of the user'sfinancial institution transaction servers or processors.

The lockbox server 3 is an authentication and processing system of theuser of the mobile registration system 1. Now that the user token 4 andthe user account 5 having been created, the user of mobile communicationdevice 2, at the mobile application, can now associate bank, credit cardinstitution, or billing agent information with the user account 5. Thisfinancial information will then be associated with user token 4 and thusassociated with user account 5 at the lockbox server 3. Upon successfulstorage of the bank credit card and/or billing agent information, thelockbox server 3, now has the ability to lock and unlock, and credit ordebit the user's financial account at the user's bank/credit cardinstitution, or billing agent. The lockbox server 3 sends confirmationthat a user account 5 has been created on the lockbox server 3 to theuser's financial institution associated with the user's financialaccounts. The user's financial accounts are then locked from billingand/or transactions from any other source outside of the financialinstitution unless the transaction has been confirmed through the useraccount 5 on the lockbox server 3.

Referring now to FIG. 2, the communications network 8 providescommunication between a point of sale unit 51 located at a merchant, andthe payment interworking server 7, which may be a cloud based orphysically located at the account holder's bank or financial serverlocation server that facilitates transactions, routing and securitybetween the point of sale unit 51 and the financial institution server10. The communications network 8 provides communication directly fromthe point of sale unit 51 to the payment interworking server 7, whichmay be a cloud based or physically located server at the accountholder's bank or financial location that facilitates transactions,routing and security between the point of sale unit 51 and the financialinstitution server 10. The communication between the communicationnetwork 8 and the point of sale unit 51 can be achieved by an IP networkwhich may comprise a plurality of different physical interconnectednetworks using an IP protocol as level three protocol (IP=InternetProtocol). But, it is also possible that the communication from thecommunication network 8 is a telephone network, for example a PSTN orISDN network (PSTN=Public Switched Telecommunication Network;ISDN=Integrated Services Digital Network). It is possible that thecommunication network 8 is a mobile network. Further, it is possiblethat the communication network 8 is formed by a network providing bothkind of services, wherein different services are used for thecommunication between the point of sale unit 51 and the paymentinterworking server 7 and between the payment interworking server 7 andthe financial institution server 10. The financial institution server 10may be at any location that houses a user's banking, debiting, creditcard or retirement account information.

A direct merchant interface in lieu of point of sale unit 51 can be acash register, a vending machine, a ticket machine or the like. Thedirect merchant may also comprise an input and output means, for examplea display, a keypad, a microphone, a loudspeaker, a mousepad and so on.Further, the direct merchant interface may comprise a communication unitfor communicating via the communication network 8 and a secondcommunication unit for communicating with the mobile communicationdevice 2 via a QR or Barcode scanner, short range interface, or thelike. Such a short range interface is, for example, an infrared or shortrange radio interface like a Bluetooth interface. It is also possiblethat the second communication unit enables a physical connection betweenthe mobile communications device 2 and the point of sale unit 51. Suchgalvanic connection is provided by a connector or mobile communicationdevice 2 docking station which allows the data interface of the mobilecommunications device 2 to receive transaction request information fromthe direct merchantmerchantmerchant and transmit the authentication andtransaction information to the lockbox server 3 to finalize thetransaction.

When a user is at the point of sale unit 51 and is ready to initiate atransaction, the amount to be paid is, for example, may be entered bythe shop keeper or cashier, scanned or communicated via short wave tothe point of sale unit 51. The user may then use a payment device, suchas a credit or debit card to begin the transaction, by swiping the cardor using a short range interface when a wallet pay application or thelike is used instead of a physical card. Alternatively, the user maycommunicate the transaction direct from the merchant to the Lockboxserver 3 or to the point of sale unit 51 using the mobile application.When the card is swiped or input directly to the point of sale unit 51or at the point of sale unit 51 from a short range interface using themobile application, the user's account information is captured by thepoint of sale unit 51. The lockbox server 3 receives the amount to bepaid and the user's account information and validates the amount to bepaid with the mobile communication device 2 for authorization to unlockthe account for deduction and lock the account upon completing thetransaction. Should the merchant use their point of sale unit 51, thepoint of sale unit 51 then transmits the amount to be paid and theuser's account information to the lockbox server 3. The lockbox server 3recognizes the account information transmitted from the point of saleunit 51 and associates the account information with the appropriate useraccount 5 (as described and created in FIG. 1). The lockbox server 3then verifies the appropriate token 4 associated with the user account 5and transmits a payment confirmation to the mobile communications device2. The user token 4 transmitted from the lockbox server 3 and the tokenpreviously stored on the mobile communications device 2 are compared andconfirmed. This process confirms that the mobile communication device 2is the correct device and correct user to approve the transaction.

Upon confirmation of the user token 4, the mobile communication device 2via the mobile application displays the amount to be paid, asking theuser to confirm the amount and approving the payment. The user may thenneed to provide a biometric scan of their biometric identifier. Aspreviously mentioned with respect to FIG. 1, the biometric identifiercan be a finger print scan, eye scan, facial recognition or any otheruniquely scanned feature of the user. When using the biometricidentifier as the approval for the transaction, the biometric identifieris compared with the biometric identifier associated with the user token4. Upon successful confirmation, the lockbox server 3 then temporarilyunlocks the user's appropriate financial account at the financialinstitution server 10 until the payment transaction request from theappropriate merchant services device 10 sends the authenticatedtransaction. When the user gives the appropriate approval, the lockboxserver 3 sends the confirmation of payment directly to the merchant (ifusing lockbox authentication/processing server directly) and the User isissued a receipt for confirmation of payment from the merchant. If themerchant is using the point of sale unit 51 instead of the lockboxserver 3 directly, then the transaction protocol is as follows: Thepoint of sale unit 51 sends the received payment data indicatingfinancial transaction request via the communications network 8 to thepayment interworking server 7. Such payment data contains, for example,the amount to be paid, the kind of billing system which shall be usedfor the financial transaction and data identifying an account of themerchant and the amount to be transferred. The payment interworkingserver 7 connects with the financial institution server 10 to processthe transaction from the user's financial account. Once the financialinstitution server 10 processes the transaction, the paymentinterworking server 7 sends confirmation back to the point of sale unit51 through the communications network 8, the point of sale unit 51 canthen send the confirmation to the lockbox server 3 that the transactionhas been processed and completed. Then the lockbox server 3 willcommunicate with the user's financial institution server 10 to lock theuser's financial account again.

Further, it is possible that the user can use a mobile pay system, suchas Apple Pay™, Intuit GoPayment™, PayPal™, etc. in lieu of swiping aphysical debit/credit card. There, the payment processing will work in asimilar manner. Using a mobile pay system, will require that the mobilepayment system, resident on the mobile communication device 2, send theappropriate debit/credit card information directly to the point of saleunit 51, as currently known in the art. From there, the paymentprocessing will proceed as described above.

In an alternate embodiment, it is possible that the user enters approvaldirectly into the point of sale unit 51. According to this embodiment,the mobile communication device 2 can remain in the pocket of the userwho stands in close proximity to the point of sale unit 51. The amountto be paid, the confirmation of the user and/or the approval of paymentby the user can be entered at the point of sale unit 51, without anyuser interaction between the mobile communication device 2 and the user.The exchange of the user token 4 can be automatically executed betweenthe point of sale unit 51 and the mobile communication device 2 via theshort range interface. The user token 4 is temporarily stored on thepoint of sale unit 51 until the transaction is completed. The shortrange interface may be a Bluetooth interface and the Bluetooth paringmechanism is used for establishing this communication. Here, uponcompletion of the temporary transfer of the user token 4 to the point ofsale unit 51, the point of sale unit 51 will send the user token 4 tothe lockbox server 3 to be authenticated as the point of communicationand confirmation for the financial transaction requests. As mentionedabove with respect to previous embodiments, a hand shake andconfirmation of the point of sale unit 51 for communication with thelockbox server 3 occurs. The lockbox server 3 recognizes the accountinformation transmitted from the point of sale unit 51 and associatesthe account information with the appropriate user account 5 (asdescribed and created in FIG. 1). This process confirms that the pointof sale unit 51 is the correct device to approve the transaction. Toensure safe keeping of the user token 4, upon completion of processingthe transaction request, the point of sale unit 51 deletes the usertoken 4.

Upon user token 4 confirmation, the point of sale unit 51 displays theamount to be paid, asking the user to confirm the amount and approvingthe payment. The user will then need to provide a biometric scan oftheir biometric identifier at the point of sale unit 51. The biometricidentifier is compared with the biometric identifier associated with theuser token 4. Upon successful confirmation, the lockbox server 3 thentemporarily unlocks the user's appropriate financial account at thefinancial institution until the payment request from the appropriatemerchant sends the authenticated transaction. When the user gives hisapproval, the lockbox server 3 sends the confirmation to the point ofsale unit 51 that the transaction is ready to be processed. The point ofsale unit 51 sends the received payment data describing the financialtransaction via the communications network 8 to the payment interworkingserver 7. The payment interworking server 7 connects with the user'sfinancial institution server 10 to process the transaction from theuser's financial account. Once the payment interworking server 7processes the transaction, the payment interworking server sendsconfirmation and confirmation is sent back to the point of sale unit 51through the communications network 8, the point of sale unit 51 can thensent send the confirmation to the lockbox server 3 that the transactionhas been processed and completed. Then the lockbox server 3 willcommunicate with the financial institution server 10 to lock the user'sfinancial account again.

The system according to FIG. 2 also depicts a method for processingautomatic billing transactions through the lockbox server 3. On themobile communications device 2, a user can schedule payments such as acar or bill payment and specify the date and time at which to processthe payment. A traditional method may be used to schedule the payment inthe mobile communications device 2 by entering the appropriate accountnumber associated with the car or bill payment, the amount to processand the date on which the transaction should be processed. Once the userpayment has been scheduled, the mobile communications device 2 will savethe information in its memory for processing on the specified date. Thisinformation is also transferred to lockbox server 3 and stored intomemory for processing.

On the day and time scheduled for the payment, mobile application willmake a transaction request to the mobile communications device 2. Theuser of the mobile communications device 2 will authenticate thetransaction in the same manner as described above by inputting theappropriate biometric scan. Upon successful comparison of the biometricscan to the user token 4, the lockbox server 3 sends communication tothe financial institution server 10 to unlock the user's financialaccount and process the transaction request. At the time of request fromthe lockbox server 3, the lockbox server 3 will transfer anauthentication to the financial institution server 10 to verify that theauthentication matches the user's financial account. Upon successfulmatch, the financial institution server 10 will then unlock the accountfor processing the transaction request. The payment funds will then bededucted from the account. The account is then locked again, uponsuccessful completion; the bank transfers the confirmation to thelockbox server 3. The lockbox server 3 then sends the payment amount tothe billing system 9 which pays the appropriate account associated withthe previously scheduled payment. The lockbox server 3 then generate anotification that the payment was successfully processed and communicatea receipt or confirmation to the user. Should the user token 4 bedenied, the lockbox server 3 immediately requests the financial accountbe locked and will collect all information details and store on theserver and pass along a notification to the mobile communications device2. All payment requests and details about the processing are stored onthe lockbox server 3 and can be view/retrieved on the mobilecommunications device 2 from the mobile application.

As shown in FIG. 3, an alternate embodiment of the lockbox server 3 asit is used in a typical retail enterprise configuration is shown. Thesystem according to FIG. 3 contains the lockbox server 3 incommunication with an LDAP database 65, and POS (Point of Sale) Images62. The LDAP database 65 is an open, vendor-neutral, industry standardapplication protocol for accessing and maintaining distributed retailinformation for services over the system of FIG. 3. The LDAP database 65contains information to facilitate communication between the point ofsale units 51 and the lockbox server 3 or directly from the point ofsale units 51 to the lockbox server 3. As examples, the LDAP database 65may provide any organized set of records, often with a hierarchicalstructure, containing the authorized point of sale units 51 that arecapable of communicating with the lockbox server 3. The POS images 62contain account, routing and transaction information for each of theretail enterprise's financial accounts. The lockbox server 3 is also incommunication with one or more branch servers 60. The branch servers 60are housed within the retailer's system network, such that theretailer's point of sale system is routes transactional details withinthe retailer's financial system. The branch servers 60 are also incommunication with every point of sale unit 51 and if the merchant usesa third party merchant service provider, to the merchant devices. Asdescribed above with respect to FIGS. 1 and 2, the point of sale units51 capture point of sale details such as a good being purchased, costs,aggregate amounts of the total transaction and the appropriate approvalsfor unlocking, and debiting a user's financial account.

In accordance with this embodiment, the lockbox server 3 securelyenables transactions from the point of sale units 51 to a user'sfinancial institution as discussed above. To enable secure transactionsand to establish communication between the lockbox server 3 and themobile communications units 51, the lockbox server 3 will initiallyprovide a mass download to each branch server 60 with instructions toenable embedded code distribution to all point of sale units 51 andmerchant servers on its respective network. The embedded code will allowan input device, at the point of sale units 51, to communicatetransactional details, such as prices, items purchased, total amount duefrom the transaction, etc. to the point of sale units 51. The inputdevice is any traditional piece of computer hardware equipment used toprovide data and control signals to the point of sale unit 51. Examplesof input devices include keyboards, mouse, scanners, digital cameras andjoysticks, etc. After the mass download is complete and the point ofsale unit 51 is are operational with the retailer accounting and routinginformation loaded, the point of sale unit 51 is enabled to communicatewith the lockbox server 3 to process transactions. The downloaded andembedded code is standalone and does not compromise or alter theretailer's existing point of sale software platform. The embedded codeis utilized to transmit and receive purchased item information from thescanning device to the point of sale unit 51. Once the item informationis received at the point of sale unit 51, the point of sale unit 51captures the user's account information from through any of: use of apayment device, such as a credit or debit card, by swiping the card, oruse of a short range interface from the mobile communications device 2when a pay pass or the like is used instead of a physical card. The usermay also communicate account information to the point of sale unit 51using the mobile application and transmission of the token 4, asdescribed above with respect to FIGS. 1 and 2. As the user's accountinformation is input at the point of sale unit 51, the user's accountinformation is captured by the point of sale unit 51. The point of saleunit 51 then transmits the item information and the user's account tothe lockbox server 3. The lockbox server 3, then verifies accountinformation against the user token 4 previously associated with user'saccount information, as described with respect to FIG. 1. Uponverification, the lockbox server 3 then interacts with the user'sfinancial institution to unlock the user's financial account, send theappropriate transactional details to the user's mobile application forverification of the debit amount. Upon verification, the lockbox serversends instructions to the financial institution to debit the appropriateamount and transfer the payment to the retail enterprise's financialinstitution based on account information read from the POS images 62.Upon completion of the transaction, the lockbox server 3 sendsinstruction to lock the user's financial account and sends verificationback to the point of sale unit 51 that the transaction has beencompleted.

Many modifications and other embodiments of the point of sale paymentsystem set forth herein will come to mind to one skilled in the art towhich these inventions pertain having the benefit of the teachingspresented in the foregoing descriptions and the associated drawings.Therefore, it is to be understood that the inventions are not to belimited to the specific embodiments disclosed and that modifications andother embodiments are intended to be included within the scope of theappended claims. Moreover, although the foregoing descriptions and theassociated drawings describe exemplary embodiments in the context ofcertain exemplary combinations of elements and/or functions, it shouldbe appreciated that different combinations of elements and/or functionsmay be provided by alternative embodiments without departing from thescope of the appended claims. In this regard, for example, differentcombinations of elements and/or functions than those explicitlydescribed above are also contemplated as may be set forth in some of theappended claims. In cases where advantages, benefits or solutions toproblems are described herein, it should be appreciated that suchadvantages, benefits and/or solutions may be applicable to some exampleembodiments, but not necessarily all example embodiments. Thus, anyadvantages, benefits or solutions described herein should not be thoughtof as being critical, required or essential to all embodiments or tothat which is claimed herein. Although specific terms are employedherein, they are used in a generic and descriptive sense only and notfor purposes of limitation.

What is claimed is:
 10. A method for point of sale purchasing usingbiometric authentication, wherein a mobile communication device having aunique identifier, is connected via a short range interface to a pointof sale unit, and wherein the point of sale unit sends a transactionrequest through a payment interworking server to a financial institutionserver upon receiving a payment request from the mobile communicationdevice.
 11. The method of claim 11, wherein the financial institutionserver reroutes the transaction request to a lockbox server upon receiptof the transaction request.
 12. The method of claim 12, wherein uponreceipt at the lockbox of the transaction request from the financialaccount server, and the lockbox server transmits data regarding thetransaction request to a processor on the mobile communication device.13. The method of claim 13, wherein upon receipt of the transactionrequest data at the processor, a mobile application requestsauthentication of the data and goes into standby mode until a verifiedbiometric identifier is received by the processor.
 14. The method ofclaim 14, wherein upon receipt of a biometric identifier at theprocessor, the processor compares the received biometric identifier witha biometric identifier stored in a user token within a memory of themobile communication device.
 15. The method of claim 15, wherein uponverifying that the received biometric identifier and the biometricidentifier in the memory are identical, the processor transmits the usertoken to the lockbox server.
 16. The method of claim 16, wherein uponreceipt of the user token at the lockbox server, the lockbox serververifies that the transmitted user token and a user token previouslystored in a memory at the lockbox server are identical.
 18. The methodof claim 17, wherein upon verifying that the transmitted user token andthe user token previously stored in the lockbox server are identical,the lockbox server initiates commands to the financial institutionserver to temporarily unlock a financial account associated with theuser token and process the transaction request.
 19. The method of claim18, wherein upon receipt of a confirmation that the processing of thetransaction request is completed, the lockbox server sends commands tothe financial institution server to lock the financial account toprevent further processing of transaction requests associated with thefinancial account and sends commands to the point of sale unit that thetransaction request has been completed.
 20. The method of claim 19,wherein the point of sale unit transmits confirmation that thetransaction request has been completed via the short range interface tothe mobile communications device.